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Method and device for maintenance 

The present invention relates to a device and method for maintain- 
ing a system in which a real process is handled. 

Necessary maintenance measures are generally carried out on an 
event-controlled or time-triggered basis. With event-controlled 
maintenance measures, a process component will be replaced or re- 
paired if it has failed. In the case of time-triggered maintenance, 
on the other hand, maintenance measures are performed at regular 
intervals, the aim being to prevent outage of the process facility. 

Preventive maintenance is of paramount importance especially where 
highly complex facilities are concerned: The outage, for instance, 
of a production facility can give rise to very high costs. That is 
why complex facilities are frequently monitored by sensors and the 
measurements used to detect a need for maintenance. This typically 
entails performing measurements on components of a facility and re- 
cording these measurements during the process. Changes in the meas- 
urements allow tendencies to be recognized that may necessitate 
maintenance measures. For example, pressure may rise in a facility 
over time, indicating a blocked pipeline, for instance. As further 
examples, vibrations may point to a worn bearing and measurements 
performed on the phase angle delta in a motor drive may indicate 
unfavorable drift. However, not in every facility can individual 
components be constantly monitored for wear and the like: Monitor- 
ing may be uneconomical in the case, for example, of very high 
process temperatures or facilities of very compact physical design, 
or if individual components are extremely complex. 

The object of the present invention is thus to improve or expand 
the possibilities of detecting a need for maintenance in facilities 
and systems. 
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This object is achieved according to the invention by means of a 
method for maintaining a system by executing a real process in the 
system, by executing a simulation process synchronously with the 
real process, with the simulation process simulating at least a 
part of the real process, by comparing the simulation process with 
the real process or said part thereof, with a comparison result be- 
ing obtained from this, and by deriving maintenance measures from 
the comparison result. 

The above object is further achieved by means of a device for main- 
taining a system on which a real process with one or more real 
process steps can be executed, with a simulation device for simu- 
lating at least a part of the real process by means of a simulation 
process, the simulation process being executable synchronously with 
the real process, with a comparison device for comparing the simu- 
lation process with the real process with a comparison result being 
obtained, and with a control device for initiating a maintenance 
measure on the basis of the comparison result. 

Production-driven maintenance can hence be advantageously facili- 
tated by the invention, with the simulation of the process running 
in parallel with the real process. During this, the simulation 
process can be supplied with, for example, associated production 
parameters . 

Further advantageous developments of the device according to the 
invention and of the method according to the invention can be found 
in the subclaims . 

The present invention will now be described in more detail with the 
aid of the attached drawings, in which 

FIG 1 shows a data flow diagram of a real process and a simulation 
process running in parallel according to the invention; 



FIG 2 shows a signal flow diagram for alerting and predicting a 
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need for maintenance; and 



FIG 3 shows a signal flowchart for implementing maintenance meas- 



ures 



The exemplary embodiments described below show preferred embodi- 
ments of the present invention. 

FIG 1 shows, in its left half, a schematic signal flowchart of a 
control of a real process and, in its right half, that of a simula- 
tion process running in parallel. The order controller or what is 
called a scheduler serves as a starting point for controlling the 
real process. A recipe control (batch flexible) is driven with the 
order data. The recipe control obtains the required recipe (s) from 
15 a database, namely the recipe administration. This drive is suit- 
able for both batch-processing processes (batch) and continuous 
processes . 

Actual facility control or automation takes place in the block in 
20 FIG 1 designated "sequence logic". A separate component between the 
recipe control and sequence logic coordinates the instructions with 
regard to semantics . 

The sequence logic is associated with several function blocks FB 
25 which are responsible for automating individual steps. Via an in- 
put/output periphery the sequence logic and function blocks then 
exchange instructions and measurements with the process components 
of the real process. A simple production process performed within a 
simplified facility could serve as an example of a real process. A 
30 container is linked to a reactor via a pipe. The reactor contains 
two generating sets, a mixer, and a heater set. The container is 
filled with a certain substance. During the production process the 
reactor could first be filled with the substance from the container 
then heat and mix said substance. The relevant process steps are 
35 filling, heating, and mixing. Each of these individual process 

steps or basic operations has its own internal sequence of instruc- 
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tion steps which is implemented in the sequence logic. The process 
step *fill' may, for example, comprise the instructions: Check 
status of cellular wheel sluice, open slide gate, check fill level 
etc. In a recipe for producing a certain substance the individual 
process steps are precisely specified. Similar to a cooking recipe, 
the control recipe contains parameters such as process times, proc- 
ess temperatures etc. A set sequence of process steps is also 
specified. 

The individual process steps are sequenced in- the sequence logic 
and the respective start and end time specified. Facility compo- 
nents are individually controlled by function modules as directed 
by the sequence logic. 

A corresponding simulation process is shown on the right-hand side 
of the figure in FIG 1. Like the real process system, the simula- 
tion system consists of a coordination module followed by the se- 
quence logic and equipment function modules. The input/output pe- 
riphery of the real process is simulated by a logical periphery. 
The real process itself must be simulated, on the one hand, in its 
components and, on the other hand, in the process flow itself. The 
components are simulated in what is called an equipment simulation, 
and the equipment simulation modules are suitably linked together 
for the process simulation. 

The logical periphery and equipment simulation can be generated 
automatically by a semantics manager from a library of RB classes 
(reaction modules) . 

Equipment master data, substance master data, and pipeline master 
data etc. flow into the process simulation. Equipment master data 
comprises, for example, the diameter of containers, features of 
valves, pumps etc. Substance master data comprises quantities, 
grain size distribution etc. of the substance used. Lastly, the 
pipeline master data corresponds to dimensions and other relevant 
variables of the pipelines used. All the master data can be filed 
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in libraries . 

According to the invention the real process is then synchronized 
with the simulation process. The two processes consequently run in 
parallel so as to make a direct comparison of the process results 
possible. It is not necessary here to simulate the entire real 
process; instead, a particularly critical process step, for exam- 
ple, can be simulated which requires, for instance, constant moni- 
toring . 

The process simulation is favorably co-controlled by the order con- 
troller of the real process. It is, however, also possible to pro- 
vide a separate control for the simulation. Moreover, the process 
simulation preferably obtains the recipes from the recipe admini- 
stration of the real process. This direct linking to the real proc- 
ess is one of the prerequisites for automatic engineering of the 
simulation. In any event it is definitely helpful for this. 

The simulation allows the entire facility and/or major parts of it 
to be simulated as a virtual facility. Selectively simulating parts 
of the facility and comparing the relevant virtual and real process 
steps allow the need for maintenance to be localized to a degree 
commensurate with the size of the simulation component. For exam- 
ple, critical parts of the facility can be subdivided into finer 
process steps in order better to localize the need for maintenance. 
Where non-critical parts of the facility are concerned, several 
components can be combined both during measuring of the real proc- 
ess and during the simulation. If a fixed deviation or a deviation 
increasing with time is then detected on the basis of the compari- 
son of the results of process steps in the real and virtual proc- 
ess, appropriate maintenance measures can be initiated. 

According to the invention the behavior of a facility from a proc- 
ess control viewpoint is examined so that a need for maintenance 
can be detected in a timely fashion. This means that, for example, 
the vibrating of a pump is not measured so that conclusions can be 
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drawn about a worn bearing; instead, the flow through the pump is 
measured and compared with a simulated ideal flow so that the 
pump's aging can be detected. 

In a development of the invention it would also be possible to 
simulate the behavior of the substance which is contained within 
the facility and being processed. Conclusions could be drawn about 
the facility from the simulated and real chemical conversion - 
process. For example, deviations in a substance's physical state, 
such a viscosity, could indicate a defective cooling device. 
Equally, differences between the simulated and measured PH value, 
for instance, could indicate a defective mixer. 

Whether the physical parameters of the substance located within the 
facility or typical variables of the facility, such as the through- 
put rate, are used for diagnostic purposes, is of secondary impor- 
tance provided the simulation process runs, according to the inven- 
tion, in parallel with the real process and individual results of 
process steps or overall results of the process as ^a whole are com- 
pared. For the respective comparison it is necessary for the start 
and end of each process step being compared to be defined and rec- 
ognized. Unique indicators for a need for maintenance can also be 
determined. For example, unusually long filling times or excessive 
heating times can be recognized that deviate from normal facility 
operation. These differences do not necessarily result in an outage 
of the entire facility or the production of rejects; they may 
merely indicate that the facility is not running according to the 
planned optimum. 

Appropriate maintenance measures can be carried out in keeping with 
* the magnitude of the deviations. Simply a warning can be directed 
to the maintenance team if there is only a slight difference be- 
tween the real and simulated process. In the case of major differ- 
ences a fault message can be issued signaling an immediate need for 
maintenance . 
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The diagnostic information obtained from parallel running of the 
real and simulated process can also be used to optimize the facil- 
ity If, for example, the facility is run using a changed recipe, 
the process steps and/or their sequence will also change. The fa- 
cility controller or scheduler converts the new recipe into time 
flows or time slices. In the case of multi-substance facilities, 
for example, these time slices must be coordinated as a function of 
the different substances and facility components. The aim here is 
to utilize all parts of the facility to optimum capacity. To im- 
prove scheduling online, the simulation process can run in parallel 
with the real process. Optimization can thereby be achieved without 
the need for the facility to be idle. 

As already mentioned, a meaningful comparison between real and 
simulated process steps requires precise synchronizing. A precise 
starting point must also be specified, which is done by initializ- 
ing As indicated in FIG 1 by a broken line, initializing of the 
simulation process can be controlled online by the sequence logic 
of the original facility. For example, it is possible to ensure 
that a container in the original facility and in the simulation has 
in each case a defined fill level at a specific process step ma 
specific recipe. 

The single arrows in FIG 1 signify signal links or action links, 
and the double arrows signify data connections which are necessary 
for, for example, parameterizing and engineering. 

FIG 2 shows a schematic signal flowchart for obtaining a mainte- 
nance request on the basis of the diagnosis resulting from the com- 
) parison between the real process and simulation process running m 
parallel. Explanations of the modules can be found in the table at 
the end of the description. 

' FIG 3 shows a signal flowchart showing further processing of a 
5 maintenance request in a maintenance management system. According 
to this, service measures are performed if necessary on the basis 
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of information provisioning, material/resource provisioning, main- 
tenance planning, and the maintenance request. Material/resource 
administration and the budget have an impact here on maintenance 
planning. The facility model also serves for information provision- 



ing. 
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Table 



Component 1 


function 1 


[■ask 


PLC 1 


Logic in TF - 

i 

1 


Suppression of follow-up 
nessage . 

Example 1: Outage of the 
alerting voltage (simul- 
taneously) takes all the 
messages from the moni- | 
toring loop fed by the 
alerting voltage ("con- j 
tacts' 7 ) . j 
Example 2: All messages 
must be suppressed in 
on-site operation (from 
a repair counter) . 

Module message 
Example 1: Check-back 
monitoring (protective j 
check-back, rotation 
speed check-back, oper- 
ating time message) 
Example 2: Operating 
mode changeover 




Process data logging 


Make process values | 
available that are re- 
quired for cross-area 
logic (event-triggered, | 
in the case of measure- 
ments for change with 
dead band) 




Logic between TFs 


Technological monitoring 
of a PLT location. | 
Example 1: A jump in j 
setpoint value on a 
regulator must result a 
rise in the actual 
value . j 
Example 2 : Manipulated 
variable of a regulator 
increases with no change 
in the setpoint value _J 
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(wear on valve seating) . 
Example 3: Pressure or 
flow measurement on pump 
group 




Usage-dependent 
maintenance 


Operating cy- 
cle/operating time 
counter 

Count the operating 
nour s or opera uiny 
cles, generate IH re- 
quest if a parameterized 
threshold is exceeded 




Section chain 
monitoring 


Time monitoring for in- 
dexing condition 


PDM 


Scan field devices 


Information from intel- 
ligent field devices 
PDM (AMS) scans the ac- 
cessible field devices 
and transfers messages 
(selected by parameter- 
izing) 

Live monitoring of in- 
telligent field devices 
PDM (AMS) scans the 
planned field devices 
and generates a message 
if a planned device can- 
not be accessed. 




Should be/as is com- 
parison 
Project 


Comparison planning - 
as is 

PDM (AMS) scans the ac- 
cessible field devices 
and generates a message 
if planning is not as is 
(read field device not 
in the project) . 


CBA 






CM 


.Condition monitoring 


Example 1: Vibration 
monitoring on machine 
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Example 2: Electrical 
fingerprint for motor 
Example 3: HISS (smell, 
hear, taste) 


HMI 


Operation of operating 
or recipe parameters 


Example: "Standard de- j 
viation" parameter for 
fault message dependent 
on operating mode 




Alarms 


Planned alarms = IH re- j 
quest 


Diag 


Facility behavior 


Comparison of current 
facility behavior with 
history. \ 
Example 1: How long has j 
it taken so far to bring j 
material x in unit y 
from m to n fill height? 
Comparison with current 
step. j 
IH request via user ac- | 
tion with GUI support. j 
User generates IH re- j 
quest 

Necessary: Facility be- 
havior archive or (at j 
least) parameterized j 
comparison values j 




Logic between TFs 


Technological monitoring 1 
of part of a facility 
Logic or rules on a j 
cross-area basis over j 
several PLT locations | 
(on several PLCs, where j 
applicable) 




Diagnostic message 


Message frequency 
Example 1: Specific re- 
port numbers from a spe- 
cific TP are (interac- 
tively) "set to diagno- 
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sis' 7 and continuously 
monitored from then on 
until a suspected fault 
cause has been recog- 
nized/analyzed. 
Example 1: Suspicion of 
increased outage rate of 
a motor drive: The re- 
port numbers, protective 
check-back, and bimetal 
message generate a diag- 
nostic message if more 
than 5 messages occurred 
per shift. 




Simulation evaluation 


Compare the result of 
process /equipment simu- 
lation with real proc- 
ess/facility results. ! 
Decision rules specify- 
ing when a comparison 
between simulation re- 
sult and as-is facility 
is ok/ not ok and (in 
the case of process 
simulation) assignment 
to asset. 




Behavior evaluation 


Compare value from fa- 
cility behavior archive 
or from facility behav- 
ior (with fixed values 
determined in IBS/trial 
operation) with real fa- 
cility results. Other- 
wise as above. 

Note: 

Q-imnl i on e*\TZi 1 nation is 
O _LJ.llLi.Xcl L, XUll V d J- liq i— x v/ii 

advantageous in the case 
of multi-purpose facili- 
ties where a meaningful 
facility behavior ar- 
chive is not ensured on 
account of the multi- 
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plicity of prod- 
ucts/recipes . 
Behavior evaluation is 
advantageous in the case 
of "single-purpose" fa- 
cilities and conti- 
/semiconti facilities . 




Sim 


Process simulation 


Technological monitoring 
of recipe steps 
SIMIT has models of the 
facility GOs (mix, heat, 
fill etc.)- Each indi- 
vidual model has para- 
meters (substance, unit, 
and product parameters) . 
The simulation runs un- 
der BF control (BF gives 
the step start, with the 
parameter set valid for 
the step and the end 
criterion (e.g. final 
temperature 92°C) , to 
SIMIT. SIMIT starts 
simulation and, on at- 
tainment of the end cri- 
terion, gives the result 
parameter set defined 
for the GO to Diag. 
SIMIT has (as yet) no 
command of substance 
conversions ; operations 
of this type (e.g. >x re- 
action", "synthesis") 
have to be simulated by 
simple empirical equa- 
tions if a pass is to be 
made through several GOs 
in a "simulation chain". 
No project-specific en- 
gineering work is neces- 
sary because this method 
runs under the control 
Of BF. SIMIT "only" 
needs models that are 
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process/project neutral . 




Equipment behavior 


Technological monitoring 
of the equipment behav- 
ior 

SIMIT has models of the 
(technological) equip- 
ment behavior (e.g. re- 
sistance heating element 
with time behavior, heat 
transition, heat flow in 
the substance etc.). 
Otherwise analogous to 
the above 


Arch 


Facility behavior 
archive 


History of the product- 
and substance- /material- 
dependent time behavior 
of parts of the facil- 
ity, units, equipment, 
and also relevant 
( fixed) parameters . 

Different embodiments 
for the process industry 
and discrete (manufac- 
turing) industry: 
Process industry: Ob- 
jects are steps in the 
flow such as filling, 
heating etc. and equip- 
ment (S 88), not the ob- 

nori-c of 1 - o f ari 1 T 1" V 

J CL Lj \J 1. L11C LCl^lXlUjf 

model such as a pump, 
regulating valve etc. 
Discrete industry: Ob- 
jects are the "machines" 
of the facility model. 





